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' DATA TRANSFERRING APPARATUS AND ITS METHOD 



BACKGROUND OF THE INVENTION 

Field of the Invention 

This invention relates to a data transferring apparatus and its method for efficiently 
transferring an image and other data. 

Description of the Related Art 



Presently, a raster interface is used to transfer image data from a computer to a 
display apparatus. However, using a raster interface requires transferring a large amount 
of data because all the pixel data is transferred from the computer to the display apparatus. 
Therefore, in cases such as connecting an ultra-high resolution display apparatus to a 
computer, if a raster interface is used to transfer image data, there is a possibility that the 
data transferring capacity of the communication channel between the computer and the 
display apparatus may not be sufficient. 



SUMMARY OF THE INVENTION 



In view of the foregoing and other problems, disadvantages, and drawbacks of the 
conventional methods and structures, an object of the present invention is to provide a 
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data transferring apparatus and its method to allow more efficient transfer of image data in 
cases such as connecting an ultra high resolution display apparatus to a computer. 

In a first aspect, a data transferring apparatus according to the present invention, is 
an apparatus to transfer from a first apparatus to a second apparatus one or more transfer 
packets as objectives of transfer, the each transfer data including commands indicating 
processes against a preliminarily assigned area, the first apparatus including means for 
merging a plurality of the transfer data meeting a certain requirement, means for 
generating transfer packets each including one or more of the transfer data of which the 
amount is within a certain range and/or one or more of the merged transfer data, and 
means for transferring the generated transfer packets to the second apparatus. 

In a second aspect, a data transferring method according to the present invention is 
a method of transferring from a first apparatus to a second apparatus transfer packets each 
including one or more of transfer data as objectives of transfer, the each transfer data 
including commands indicating processes against a preliminarily assigned area, and the 
first apparatus being capable of: merging a plurality of the transfer data meeting a certain 
requirement, generating transfer packets each including one or more of transfer data of 
which the amount is within a certain predetermined range and/or one or more of the 
merged transfer data; and transferring the generated transfer packets to the second 
apparatus. 

In yet another aspect, a programmable storage medium involved in the invention is 
a program for transferring transfer packets each including one or more of transfer data as 
objectives of transfer from a first apparatus to a second apparatus, the each transfer data 
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including commands indicating processes against a preliminarily assigned area, and the 
first apparatus capable of making a computer execute the steps of merging the transfer 
data meeting a certain requirement, generating transfer packets each including one or 
more the transfer data of which the amount is within a certain predetermined range and/or 
one or more the merged transfer data, and transferring the generated transfer packets to the 
second apparatus. 

The present disclosure relates to subject matter contained in Japanese Patent 
Application No. 1 1-287268, filed October 7, 1999, which is expressly incorporated herein 
by reference in its entirety. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other purposes, aspects and advantages will be better 
understood from the following detailed description of a preferred embodiment of the 
invention with reference to the drawings, in which: 

Fig. 1 is a diagram showing the configuration of an image processing apparatus 1 
to practice an image processing method of the present invention; 

Fig. 2 is a diagram showing a sample configuration of a video controller shown in 

Fig. 1; 

Fig. 3 is a diagram showing a sample configuration of a sign control apparatus 14 
on the side of computer 10 as shown in Fig. 1; 

Fig. 4 is a diagram showing a sample configuration of a sign control apparatus 1 8 

JA999-169 3 



on the side of a display apparatus 16 shown in Fig. 1; 

Fig. 5 is a diagram showing the configuration of the display control apparatus 
shown in Fig. 1 ; 

Fig. 6 is a diagram showing the configuration of an image processing program of 
5 the present invention; 

Fig. 7 is a diagram showing a sample of data auto format of a graphics Application 
Program Interface (API) issued to an operating system (OS) by an application program 
shown in Fig. 6; 

Fig. 8 is a diagram showing a sample of drawing command issued the by OS (Fig. 
0 6) to a graphics driver; 

Fig. 9 is a flowchart that shows the processing of command analysis routine (S10) 
conducted by the graphics driver (Fig. 6); 

Fig. 10 is a diagram showing a sample of data output from command analysis 
routine as the result of processing; 
5 Fig. 1 1 is a diagram showing the status change of a scheduler (Fig. 6); 

Fig. 12 is a flowchart that shows the processing of a function IsExecutable (SI 2) 
shown in Table 3; 

Fig. 13 is a flowchart showing the processing of a function EnQ (SI 6) shown in 
Table 3; 

0 Fig. 14 is a flowchart showing the processing of a function DeQ (SI 8) shown in 

Table 4; 

Fig. 15 is a flowchart showing the processing of a function ACK (S20) shown in 
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Fig. 11; 

Fig. 16 is a flowchart that shows the processing of a timer event handler 
AckTimeout shown in Fig. 11; 

Fig. 17 is a flowchart showing the processing of a communication controller (S24) 
shown in Fig. 6; 

Fig. 18 is a sequence chart of items selected from the entire operations of the 
image processing apparatus (Fig. 1) to show specifically the process from the stage where 
drawing commands are issued from the application program (Fig. 5) to the stage when 
they enter the queue of the scheduler via the OS and others; and 

Fig. 19 is a sequence chart showing the process where the communication 
controller (Fig. 6) picks up drawing commands from the queue of the scheduler and 
transfers them to the display apparatus. 



DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS OF THE INVENTION 

Referring now to the drawings, and more particularly to Figures 1-19, there are 
shown preferred embodiments of the method and structures according to the present 
invention. 
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# • 

First Embodiment 

Fig. 1 shows a configuration of an image processing apparatus for performing an 
image processing method of the invention. 

As shown in Fig. 1, the image processing apparatus 1 includes computer 10 and 
display apparatus 16 which are connected via communication channel 22. 

Computer 10 includes CPU 102 including a general-purpose CPU and its 
peripheral circuits, etc., main storage unit 104 including RAM and its peripheral circuits, 
etc., secondary storage unit 1 12 such as a hard disc apparatus or a CD-ROM apparatus, 
video controller 12, frame memory 1 14, and sign control apparatus 14, all of these being 
connected via system bus 100, bridge 106, and input/output (IO) bus 110. 

In other words, computer 10 is configured as a general -purpose computer with 
necessary image processing functions. 

Display apparatus 16 includes sign control apparatus 18, display control apparatus 
20, frame memory 162, and display device 160. 

Fig. 2 illustrates a sample configuration of video controller 12 shown in Fig. 1. 
Video controller 12 includes, as shown in Fig. 2 for example, IO bus controller 120, 
drawing engine 122, frame memory controller 124, and communication control apparatus 
126. 

Based on these configuration elements, video controller 12 carries out a drawing 
processing in accordance with the drawing command from CPU 102 and stores the image 
data obtained as the result thereof in frame memory 114. 

Video controller 12 also transfers drawing commands, etc. between itself and sign control 



JA999-169 



6 




apparatus 14 or display apparatus 16. 

Frame memory controller 124 (Fig. 2) serves to mediate the memory access 
demands among 10 bus controller 120, drawing engine 122, and communication control 
apparatus 126, and to control refreshing of frame memory 114. 
5 10 bus controller 120 interfaces 10 bus 1 10 with corresponding components of 

video controller 12. 

Drawing engine 122 generates image data in accordance with drawing command 

J from CPU 102 and stores the data in frame memory 1 14. The drawing commands include 

m 

CO such items as Bit Block Transfer (BitBlt), linear/curve drawing, and font realization. 

pi 

W 10 Communication control apparatus 126 receives drawing commands from CPU 102 and 

ru 

^ y transfers them to display apparatus 16 via sign control apparatus 14. When such drawing 
^ commands include pixel information in the frame memory, then communication control 

Q apparatus 126 reads out pixel data from frame memory 1 14 and transfers them to sign 

□ 

S3 control apparatus 14. Communication control apparatus 126 also receives ACK signals 
1 5 which are sent from display apparatus 1 6 in order to notify the completion of drawing 
commands. 

Frame memory 1 14 (Fig. 1) stores temporary image data such as pattern data and 
font data as well as pixel data displayed by display apparatus 16. The area in frame 
memory 1 14 storing image data such as pattern data and font data is also called an 
2 0 "off-screen memory area". 

Fig. 3 shows a sample configuration of sign control apparatus 14 on the side of 
computer 10 shown in Fig. 1. 
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As illustrated in Fig. 3, sign control apparatus 14 includes video encoder 140 and 
DDC master controller 142. Based on these components, sign control apparatus 14 
encodes the drawing commands received from video controller 12 and transfers them to 
display apparatus 16. Sign control apparatus 14 also receives ACK signals indicating the 
completion of drawing commands from display apparatus 16 and outputs them to video 
controller 12. 

Video encoder 140 transfers the drawing command received from communication 
control apparatus 126 (Fig. 2) of video controller 12 to display apparatus 16 via 
communication channel 22. DDC master controller 142 transfers the ACK signal from 
display apparatus 16 to communication control apparatus 126. 

Fig. 4 shows a sample configuration of sign control apparatus 1 8 on the side of 
display apparatus 16 shown in Fig. 1. As illustrated in Fig. 4, sign control apparatus 18 of 
display apparatus 16 includes video decoder 180 and DDC slave controller 182. 
Sign control apparatus 18 corresponds to sign control apparatus 14 of computer 10 and 
outputs the data received from computer 10 to display control apparatus 20. 

Video decoder 180 corresponds to video encoder 140 (Fig. 3) of computer 10 and 
receives image data etc. from computer 10 and outputs them to display control apparatus 
20. 

DDC slave controller 182 corresponds to DDC master controller 142 (Fig. 3) of 
computer 10 and transfers ACK signals to computer 10. 

Display apparatus 160 preferably is a cathode ray tube (CRT) display, a liquid 
crystal display, or a plasma display, and displays visually the image data input from 
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display control apparatus 20 to the user of image processing apparatus 1. 

Fig. 5 illustrates a configuration of display control apparatus 20 shown in Fig. 1. 
As shown in Fig. 5, display control apparatus 20 of display apparatus 16 includes 
communication control apparatus 200, drawing engine 202, frame memory controller 204, 
5 and display device controller 206. Based on these components, display control apparatus 
20 executes drawing processes in accordance with drawing commands from computer 10, 
and stores the generated image data in frame memory 162 of display apparatus 16. 

Display control apparatus 20 refreshes the image on the display device 160 at a 
designated cycle in accordance with the model of display device 160 (i.e. approximately 
10 between 60 Hz and 85 Hz). 

In the same manner as frame memory controller 124 (Fig. 2) of computer 10, 
frame memory controller 204 serves to mediate the memory access demands between 
drawing engine 202 and display device controller 206 and to control refreshing of frame 
memory 162. 

Display device controller 206 reads out pixel data of all the displayed pixels at a 
certain cycle from frame memory 162, transfers them to display device 160, and refreshes 
the images displayed on the display device 160. 

Drawing engine 202 carries out image processing in accordance with the drawing 
commands from sign control apparatus 18, and stores the generated image data in frame 
20 memory 162. 

Communication control apparatus 200 receives and transfers drawing commands 
and ACK signals between itself and computer 10. Frame memory 162 stores the copy of 
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image data stored in frame memory 1 14 of computer 10. In other words, frame memory 
162 stores the image data (e.g., pattern data and font data, etc.) temporarily stored in 
off-screen memory as well as pixel data displayed on display apparatus 16. 

Among the components having important functions of the present invention are the 
video controller (hardware), the display control apparatus (hardware), and the graphic 
driver (software). In the configuration shown in Fig. 1, it is assumed that the video 
controller and the display control apparatus provide drawing functions as hardware, while 
the graphic driver controls each drawing command. The present invention is not 
dependent on whether it is hardware or software that materializes these three components. 
For instance, it is possible for the video controller to control, by hardware, drawing 
commands, just the same as the device driver does. Conversely it is also possible to attain 
video controller functions by software. In the latter case, frame memory is assigned in the 
main storage and the CPU makes a drawing on the main storage. In this case, the sign 
control apparatus in the computer transfers the image information, as well as a drawing 
command stored in the main storage, to the display apparatus. 

Fig. 6 illustrates a configuration of the image processing program 3 of the present 
invention. As shown in Fig. 6, the image processing program 3 includes application 
program 30 (300-1 to 300-N), operating system (OS) 32, graphics driver 34, timer 36, and 
communication controller 40. 

Image processing program 3 is, for example, recorded in recording media 38 (Fig. 
1) or is provided to the secondary storage unit 1 12 of computer 10 via network (not 
illustrated), and then is loaded on main storage 104 from secondary storage unit 1 12 to 
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materialize the image processing method of this invention. 

Application program 300-1 to 300-N (simply written as "application program 30" 
collectively when it is not necessary to specify any particular program) is, for example, an 
image processing program respectively to generate image data and requests OS 32 for 
image processing by graphics API (Application Program Interface) which displays 
generated image data on display apparatus 16 (Fig. 1), and have frame memory 1 14 store 
the image data. Application program 30 also requests OS 32 to read out the image data by 
graphics API in the same manner, so that the image data is read out from frame memory 
114. 

The data to be processed by application program 30 varies depending on the 
contents of processing and cannot be decided uniquely. For instance, the data as the 
object of application program 30 is static image data when application program 30 
displays static images, but it is MPEG data when application program 30 displays 
animated images, and is text data when application program 30 displays characters. 

Fig. 7 illustrates a sample data format which is transferred to OS 32 from 
application program 30 when application program 30 calls graphics API, as shown in Fig. 
6. The processing result of application program 30 is a couple of parameters attached to a 
call for graphics API provided by OS 32, and the kinds of the graphics API are dependent 
on the specifications of OS 32, For instance, when application program 30 requires BitBlt 
of Win32 system as graphics API, as shown in Fig. 7, a graphics API is called with each 
data such as attributes of drawing areas (to specify drawing location, e.g. whether it is 
screen or buffer in the main storage), the coordinates of a drawing location (to show, for 
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• instance, the coordinates of the upper left corner of the rectangular drawing area), a size of 
the drawing area (width and height of the rectangular drawing area), attributes of the 
source area, the coordinates of the source area (the coordinates of the upper left corner of 
the rectangular source area; however, it is unnecessary to specify the area size since it is 
5 the same as the size of the drawing area), and ROP (which designates the arithmetic 
method of bit operation). 

OS 32 may be an operating system such as OS2 (IBM) or Windows (Microsoft). 
OS 32 receives graphics requirement (drawing command) from application program 30 
with graphics API and outputs it to graphics driver 34. Furthermore, as the need arises, OS 
1 0 32 converts drawing command received from application program 30 into another type of 
drawing command that can be processed by graphics driver 34 and outputs it to graphics 
driver 34. For instance, assuming that OS 32 is Microsoft's Windows NT®, and although 
it receives BitBlt (Bit Block Transfer) command with API from application program 30, 
graphics driver 34 does not support BitBlt command, OS 32 converts the BitBlt command 
1 5 into a different command that can be executed by graphics driver 34 (e.g. CopyBits 
command) and outputs it to graphics driver 34. 

OS 32, as the occasion demands, converts the parameters of the drawing command 
into a format that can be processed by graphics driver 34, and outputs it to graphics driver 
34. For instance, in the event that a part of the area that is the object of the image 
2 0 processing extends out of the screen or is hidden behind the window of another 
application program 30, the operating system 32 applies a clipping process to the 
processing area and rectifies the coordinates of the drawing area (Fig. 7). 
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Fig. 8 illustrates a sample data attached to drawing command that OS 32 (Fig. 6) 
requires to graphics driver 34. As shown in Fig. 8, when OS 32 requires a BitBlt as a 
drawing command to graphics driver 34, in this BitBlt command are attached the data 
received from application program 30 via graphics API (e.g., such as attributes of drawing 
5 areas) and data converted from and/or added to the data from application program 30 by 
OS 32 (e.g., coordinates of a mask pattern etc.). 

According to the operations of scheduler 344 and communication controller 40, 
timer 36 carries out timer functions to monitor a timeout of waiting for the receipt of ACK 
signal that indicates the completion of processing at display apparatus 16, responding to 
1 0 each drawing command transferred from computer 1 0 to display apparatus 16 or 

responding to respective command group that contains a plurality of drawing commands. 

Fig. 9 is a flowchart showing the processing of command analysis routine 340 
(S10) of graphics driver 34 (Fig. 6). Command analysis routine 340 of graphics driver 34 
analyzes the drawing commands input from OS 32, and in accordance with the result of 
1 5 analyses controls the operation of other components of graphics driver 34. 

As shown in Fig. 9, at step 100 (SI 00), command analysis routine 340 calls a 
function provided by scheduler 344 (e.g., IsExecutable function) with drawing command 
received from OS 32 and inquires scheduler 344 as to whether the drawing command is 
immediately executable. Scheduler 344 notifies command analysis routine 340 whether 
2 0 the drawing command in question is executable or not by checking the dependency with 
other drawing commands. When a drawing command is executable, it proceeds to process 
SI 02. Otherwise, it stays at process SI 00 until such command becomes executable. 
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At step 1 02 (S 1 02), command analysis routine 340 issues to drawing routine 342 a 
drawing command to activate drawing routine 342. The drawing routine 342 carries out 
drawing operation in accordance with the drawing command input from command 
analysis routine 340, and writes in frame memory 1 14 the image data obtained as the 
5 result of the drawing operation. 

At step 104 (SI 04), command analysis routine 340 passes scheduler 344 a drawing 
command by calling a function (EnQ function). Upon receipt of this function call, 
scheduler 344 carries out processes such as transferring the drawing command to display 
apparatus 16. 

1 0 Fig. 1 0 illustrates a sample data to be output as a result of the processing 

conducted by command analysis routine 340. As shown in Fig. 10, command analysis 
routine 340 issues to drawing routine 342 as well as scheduler 344 the drawing commands 
which contain the data peculiar to the command such as parameters of drawing commands 
received from OS 32 (Fig. 8) attaching each command with a header indicating the kind 
1 5 and length of command. In the result of processing as shown in Fig. 1 0, the kind of 
commands shows the kind of drawing commands to be processed by scheduler 344 and 
display apparatus 16 (Fig. 1), which is different from the kind of drawing commands 
provided by operating system 32. 

Command analysis routine 340 converts the drawing command given from 
2 0 operating system 32 into a format that is processible for scheduler 344 and display 
apparatus 16, and issues them to the corresponding components of these apparatus. 
For instance, when command analysis routine 340 receives BitBlt from operating system 
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32, command analysis routine 340 converts it into drawing command supported by display 
apparatus 16 such as BitBltSourceCopy, BitBltPatternCopy, and BitBltDestinationlnvert, 
etc. In the event that command analysis routine 340 received a drawing command not 
supported by display apparatus 16, command analysis routine 340 may in some cases 

5 convert a drawing command into a command of pixel transfer mode (X- IMAGE). 

The length of data (Fig. 10) designates the size of data format that varies in 
accordance with the kind of drawing commands. The data proper to command is the data 
peculiar to each command. For instance, when BitBlt is received from OS 32 as a 
drawing command, command analysis routine 340 interprets the data shown in Fig. 8 as 

0 the data proper to the command as is. The data processed by scheduler 344 and 

communication controller 40 as described hereunder takes the same format as command 
analysis routine 340 as illustrated in Fig. 10. 

Fig. 1 1 shows the status change of scheduler 344 (Fig. 6). As shown in Fig. 11, 
scheduler 344 receives drawing commands from command analysis routine 340, and 

5 carries out processes such as changing their execution sequence or merging them 
adequately in accordance with the mutual dependency of the drawing commands among 
themselves, and issues to communication controller 40 the drawing commands obtained as 
the result of such processing. At scheduler 344, the status of drawing commands is 
deemed to be either one of the following three: 
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Table 1 

Status of Drawing Commands at Scheduler 344 

Status 1 : Pending 

A status where the relevant command has already been issued to display apparatus 16 
5 (Fig. 1), however, corresponding ACK signal has not been returned from display 
apparatus 16. 
Status 2: Ready 

A status where the relevant command is not dependent on other drawing commands and is 
readily transferable to display apparatus 16 any time. 
0 Status 3: Dependent 

A status where the relevant command is dependent on other drawing commands 
and is not ready to be transferred to display apparatus 16 immediately. 

The status 3 (Dependent status) shown in Table 1 is defined as the status of 
drawing commands where either one of the following conditions (e.g., see Table 2 below) 
5 is established, and the drawing command in the Dependent Status is never transferred 
from scheduler 344 to display apparatus 16 (Fig. 1) until other drawing commands having 
dependent relations with said command have been completed. 
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Table 2 

Definition of Dependent Status 

Condition 1-1: 

There are uncompleted drawing commands (Y-OP X) which take the drawing areas of the 
5 relevant drawing command (X^IMAGE, X^OP, X^OP Z) as its source operand. 
Condition 1-2: 

There are uncompleted drawing commands (X<-IMAGE, X<-OP, X<-OP Z) which are 
going to draw in areas indicated by source operand X of the relevant drawing command 
(Y-OP X). 

0 Scheduler 344 changes the status of each drawing command as the occasion 

requires when there is a possibility that interdependent relations among the drawing 
commands changes due to merging of drawing commands or due to the returning of an 
ACK signal for a certain drawing command from display apparatus 16. 

There are various methods available theoretically to control the status of drawing 

5 commands. However, one of them is to utilize the queue that corresponds to each of the 
above three statuses. 

A status control method using such a queue will be explained hereunder. For 
instance, scheduler 344 provides command analysis routine 340 with the following two 
functions shown in Table 3 : 
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Table 3 

Function provided by Scheduler 344 for Command Analysis Routine 340 

Function 1-1: IsExecutable 

Examines whether or not the drawing command from operating system 32 is immediately 
5 executable. 

Function 1-2: EnQ 

Puts the drawing command from operating system 32 under the control of scheduler 344 
to be in either Ready status or Dependent status. 

In this status control method utilizing queues, scheduler 344 adds the drawing 
0 command attached to the function input from command analysis routine 340 onto the end 
of a Ready Queue or Dependent Queue. The following is further detailed explanation on 
function IsExecutable. 

When processing is requested by command analysis routine 340, function 
IsExecutable of scheduler 344 makes judgment as to whether or not the drawing command 
5 issued from OS 32 to command analysis routine 340 is executable and returns the result of 
judgment (TRUE/FALSE) to command analysis routine 340 (i.e. executability 
confirmation of command). 

Function IsExecutable makes a judgment that the drawing command is not 
executable when both of the following conditions exist. The reason why the drawing 
0 command is judged not executable is because, for instance, if the drawing command from 
OS 32 (X*-IMAGE etc.) is executed and image data is written into frame memory 1 14 
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(Fig. 1)' under such conditions, the execution result of the drawing command X'«-IMAGE 
is not reflected correctly to frame memory 162 of display apparatus 16, thus the end result 
of the execution of the drawing command Y^OP X" becomes incorrect. 

However, in some cases the areas of X and X' are the same while in other cases 
they overlap partially each other. If X, and X' are partially overlapped, it is possible that 
the drawing command is divided into two commands, one drawing in intersection of X 
and X', and the other drawing in other area. And the drawing area of drawing command 
XVIMAGE itself is overwritten by X-IAMGE later, therefore, it does not matter whether 
or not the above result is incorrect. 

Table 4 

Conditions when Drawing Commands are Judged Not Executable 

Condition 2-1: 

There is another uncompleted command in pixel transfer mode (X'<-IMAGE, X and X 
overlapping) which is going to draw in the same drawing area as the relevant drawing 
command (X-IMAGE, X-OP, X-OP Z). 
Condition 2-2: 

After the drawing command X'<-IAMGE, there is another drawing command in Dependent 
status (Y^-OP X", X f and X" overlapping) which has X' as its source operand. 

However, even when the conditions shown in Table 4 exist, there are some cases 
that a not-executable command becomes executable on condition that scheduler 344 
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makes adequate 'Conversion of a plurality of interdependent drawing commands. For 

instance, in the above case, if function IsExecutbale converts the drawing command in 

command transfer mode Y<-OP X" to a drawing command in a pixel transfer mode Y+- 

IAMGE, then the drawing command X^IAMGE becomes executable. 

5 A judgment as to whether drawing commands should be converted or not, for 

instance, can be made based on such criteria that IsExecutable corrects/converts a drawing 

command containing an source operand within to drawing commands in pixel transfer 

" mode only when the data transfer volume on channel 22 can be reduced, based on an 

rg assumption that the transfer capacity of channel 22 between computer 10 and display 

|y 10 apparatus 16 is the bottleneck of image processing apparatus 1 (Fig. 1). 
iU 

*9 When a drawing command is executable, function IsExecutable judges whether the 

IZ drawing command is either in Ready status or Dependent status. If it is judged to be in 
jk Dependent status, function IsExecutable then judges which drawing commands have 
C3 interdependent relations with the drawing command and stores the judgment result in 
1 5 Dependency List. Function IsExecutable also cancels an old command and merges it with 
a new command when a drawing command is executable and there is another 
uncompleted drawing command in pixel transfer mode which is going to draw in the area 
overlapping with the area of the relevant drawing command. 

Fig. 12 is a flowchart that illustrates the processing of IsExecutable (SI 2) shown in 
2 0 Table 3. In order to materialize the processing thus far explained, as shown in Fig. 12, at 
step 120 (SI 20) function IsExecutable judges whether or not there is any uncompleted 
drawing commands in pixel transfer mode (X<- IMAGE) which are going to draw in the 
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area same as the given drawing command, and if there is no such command it judges that 
merging is not feasible (SI 22) and proceeds to process SI 36, and in the other contrary 
case, it judges that merging is feasible (SI 24) and proceeds to process SI 26. 

At step 126 (SI 26), function IsExecutable judges whether there are any other 
drawing commands of Dependent status having the drawing area X as their source 
operand (Y<-OP X) after the command judged to be capable of merging at step 124, and if 
there are any, it proceeds to process SI 28, and in the other contrary case, it proceeds to 
process SI 36. 

At step 128 (SI 28), function IsExecutable judges whether it is feasible by means 
of merging to offset the data volume increase on channel 22 (Fig. 1) that is caused by the 
change of drawing command in command transfer mode which is found at step 126 
(SI 26) to drawing command in pixel transfer mode (Y^IMAGE). If it is feasible to 
offset, then it proceeds to process SI 32. Conversely, if it judges that it is not feasible 
(SI 30), the process is terminated. 

At step 132 (SI 32), function IsExecutable converts the drawing command Y<-OP 
X into the drawing command Y<-IMAGE. 

At step 134 (SI 34), function IsExecutable converts the status of drawing command 
Y-IMAGE that is obtained in process SI 32 into Ready status. 

At step 136 (SI 36), function IsExecutable judges whether or not there are any 
other drawing commands having drawing area X as their source operand (Y-OP X). If 
there are any, then it adds the drawing command Y<-OP X in the Dependency List (SI 38), 
and in the other, contrary case it proceeds to process SI 40. 
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At step 140 (SI 40), function IsExecutable judges whether or not there are any 
other drawing commands (Z«-)which will draw to the same area as the source operand Z 
of relevant drawing command (X^OP Z). If there are any, it adds the drawing command 
Z<- onto Dependency List (SI 42), and in the other contrary case, it proceeds to process 
SI 44. 

At step 144 (SI 44), function IsExecutable judges whether or not there are any 
drawing commands which are judged to be capable of merging at step 124. If there are 
any, it merges them (SI 48), and in the other, contrary case it terminates the processing. 

Function EnQ is explained further in detail hereunder. Function EnQ of scheduler 
344 (Fig. 6) sets the drawing commands received from command analysis routine 340 in 
the Ready status or Dependent status, and adds them on to the end of either Ready Queue 
(Fig. 1 1) or Dependent Queue respectively. 

Function EnQ is called by command analysis routine 340 when function 
IsExecutable returns TRUE to command analysis routine 340, i.e., a drawing command 
input from OS 32 is judged to be immediately executable. 

Judgment of status (i.e., either Ready or Dependent) is made by function 
IsExecutable, based on which function EnQ changes the status of drawing commands 
accordingly. In other words, function EnQ interprets drawing commands to be in 
Dependent status when Dependency List is not vacant, and will not change the drawing 
command to Ready status until all the drawing commands that have interdependent 
relations with the relevant drawing command have been completed. On the other hand, 
when the Dependency List is vacant, function EnQ sets the drawing command in Ready 
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status since it is,feasible to transfer said drawing command to display apparatus 16 
immediately. The drawing command set in Ready status is then transferred by function 
DeQ (to be explained later in reference to Table 5 etc.) to display apparatus 16. 

For instance, in a data transfer from display apparatus 16 to computer 10 (Uplink) 
with high latency on communication channel 22, there is a possibility that data transfer 
becomes very inefficient a method is used to transfer ACK signals from display 16 to 
computer 10 upon completion of each drawing command. To cope with such cases, 
preferably a method is used to give a same group ID to a plurality of drawing commands 
so that one ACK signal is shared by a plurality of drawing commands contained in the 
group. Function EnQ carries out a role of such grouping of drawing commands and 
assigning of a group ID. 

When the data transfer volume of a group exceeds a certain amount, a re-transfer 
cost inevitably increases when an error occurs on channel 22. Therefore, function EnQ 
sets EndOfGroup flag onto the last command to close the group when the data volume of 
a group has exceeded a predetermined threshold value, considers the drawing commands 
input from OS 32 thereafter to be in a new group, and then assigns them a new group ID. 

Fig. 13 is a flowchart that illustrates the processing of function EnQ (SI 6) shown 
in Table 3. As shown in Fig. 13, at step 160 (S160) function EnQ judges whether or not 
there are any uncompleted drawing commands which have interdependent relations with 
the relevant drawing command. If there are any, it proceeds to process SI 62, and in the 
other, contrary case it proceeds to process SI 64. 

At step 162 (SI 62), function EnQ adds the drawing command to Dependent 
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Queue. 

At step 164 (SI 64), function EnQ assigns the group ID then in use to the drawing 
command. 

At step 166 (SI 66), function EnQ judges whether or not the total data volume is 
larger than threshold N. If it is larger, then it proceeds to process S168. Otherwise, it 
proceeds to process SI 70. 

At step 168 (SI 68), function EnQ closes the group in order not to add a new 
drawing command to the group which is the objective of the processing at the time. 

At step 170 (SI 70), function EnQ adds the drawing command to Ready Queue 
(Fig. 11). 

Scheduler 344 provides communication controller 40 with the following two 
functions shown below in Table 5. 

Table 5 

Functions provided by Scheduler 344 for Communication Controller 40 

Function 2-1: DeQ 

Pick up one drawing command of "Ready" status (Table 1) from the top of Ready Queue 
(Fig. 11) and pass it to communication controller 40. At the same time, change the status 
of the drawing command to "Pending" and move it to the end of Pending Queue. 
Function 2-2: AcK 

When an ACK signal is returned from display apparatus 16, renew the 
interdependence relations between drawing commands within scheduler 344. 
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Function DeQ is further explained in detail hereunder. Function DeQ picks up the 
oldest drawing command of Ready status (i.e. from the top of Ready Queue), passes it to 
communication controller 40, and then change the status of the passed drawing command 
to "Pending" status. 

When transferring drawing commands as a group to display, function DeQ closes 
the group at the time when all the drawing commands of "Ready" status have been 
processed and nothing more exists, sets EndOfGroup flag onto the last command in the 
same manner as function EnQ, and assigns a new group ID. 

Fig. 14 is a flowchart that shows the processing of function DeQ (SI 8) shown in 
Fig. 1 1. As shown in Fig. 14, at step 180 (SI 80) function DeQ judges whether or not 
Ready Queue (Fig. 1 1) is vacant. If vacant, it terminates the processing, and in the other, 
contrary case it proceeds to process SI 82. 

At step 182 (SI 82), function DeQ picks up one drawing command from the top of 
the Ready Queue. 

At step 184 (SI 84), function DeQ judges whether or not Ready Queue is vacant. If 
vacant, it proceeds to process SI 86, and in the other, contrary case it proceeds to SI 88. 
At step 186 (SI 86), function DeQ closes the group. 

At step 188 (SI 88), function DeQ adds the drawing command to the end of 
Pending Queue. 

Upon receipt of ACK signals from display 16, Function ACK suspends the timer 
processing corresponding to the group of ACK signal, if the timer processing is active. 
The timer processing is activated by communication controller 40 immediately after 
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drawing commands have been transferred, to process errors in case ACK signals for 
respective group of drawing commands transferred to display apparatus 16 are not 
properly returned. 

At this stage, if the timer processing corresponding to the received ACK signal 
was suspended, a timer event occurred and error processing has been under way. 
Therefore, function ACK simply terminates the process without doing anything. When the 
timer is suspended, function ACK deletes from scheduler 344 the drawing commands (of 
Pending status) which belong to the group the relevant ACK signal was returned to. In 
some cases interdependent relations among drawing commands may be canceled when 
drawing commands of Pending status are deleted. Function ACK looks for drawing 
commands which have interdependent relations with any drawing commands 
corresponding to the received ACK signals. Then if, among the drawing commands 
located, there are any drawing commands whose interdependent relations are canceled, it 
changes the status of such drawing commands to Ready. 

Function ACK is further explained in detail hereunder. Fig. 15 is a flowchart that 
shows the processing of function ACK (S20) shown in Fig. 1 1. As shown in Fig. 15 at 
step 200 (S200), upon receipt of ACK signals from display 16, function ACK judges 
whether or not the processing of timer 36 (Fig. 6) corresponding to the relevant ACK 
signal is active. If active, it proceeds to the processing of S202, and in the other, contrary 
case, it proceeds to process S204. 

At step 202 (S202), function ACK suspends the processing of timer 36 that 
corresponds to the ACK signal received in the process of S200. 
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At step 204 (S204), function ACK deletes from Pending Queue all the drawing 
commands which belong to the group that corresponds to the ACK signal received in the 
process of S200. 

At step 206 (S206), function ACK deletes the drawing commands which were 
deleted in the process of S204 from the Dependency List of drawing commands which 
have interdependent relations with those deleted in the process of S204. 

At step 208 (S208), function ACK judges whether or not Dependency List 
becomes vacant after the drawing commands were deleted in the process of S206. If 
vacant, then it proceeds to the process of S210, and in the other, contrary case it 
terminates the processing. 

At step 210 (S210), function ACK moves the drawing commands from Dependent 
Queue to Ready Queue when it is judged that the items corresponding thereto have been 
vacated from Dependency List in the process of S208. 

Furthermore, in the event that ACK signals are not returned from display apparatus 
16 and errors occur, scheduler 344 provides timer event handler, i.e., function 
AckTimeout, which picks up drawing commands which caused errors from Pending 
Queue (Fig. 1 1), changes them from "Pending" status to "Ready" status, and then moves 
the commands to the end of Ready Queue in order to process errors. 

Function AckTimeout is called up by the occurrence of a timer event that is 
activated by timer 36 when drawing commands transferred from computer 10 to display 
apparatus 16 is not completed normally, and an ACK signal is not returned to computer 
even after a lapse of certain time. 
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Function AckTimeout sets EndOfGroup flag onto the last one of the drawing 
commands of Ready status left in scheduler 344, and increments the value of group ID. 
After this processing, scheduler 344 re-registers the drawing commands in the group 
which caused errors as the ones in a new group, and furthermore changes the status of the 
drawing commands which belong to the error group from "Pending" to "Ready" status. 
The drawing commands re-registered in this manner are re-transferred to display 
apparatus 16 by communication controller 40. 

Fig. 16 is a flowchart that shows the processing of timer event handler 
AckTimeout (S22) shown in Fig. 1 1. As shown in Fig. 16, at step 220 (S220) function 
AckTimeout closes the group of drawing commands which are left in Ready Queue. 
In other words, the function AckTimeout sets up EndOfGroup flag onto the last drawing 
command left in Ready Queue, and increments the value of the group ID. 

At step 222 (S222), function AckTimeout assigns a new group ID to all the 
drawing commands that belong to the group which had errors, and moves them from the 
Pending Queue to the Ready Queue. 

Drawing routine 342 (Fig. 6), for instance, utilizes drawing engine 122 (Fig. 2) to 
perform graphics arithmetic that is necessary for the execution of drawing commands 
input from command analysis routine 340, generates image data, and stores them in frame 
memory 114. 

Communication controller 40 (Fig. 6) picks up the drawing commands of "Ready" 
status from scheduler 340. Communication controller 40 also reads out pixel data from 
frame memory 1 14 if necessary, generates packets that contain drawing commands as well 
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as relevant pixel data, and transfers the generated packets to display apparatus 16 utilizing 
communication control apparatus 126 (Fig. 2). When the system is set such that an ACK 
signal is received corresponding to each drawing command, communication controller 40 
activates timer 36 to monitor a timeout each time it transfers a packet. In order to set up 
the system so as to receive ACK signals for each group which includes a plurality of 
drawing commands respectively, communication controller 40 checks the EndOfGorup 
flags contained in the drawing commands during the process of packet generation, and 
operates timer 36 after transferring the packet that corresponds to the last drawing 
command in the said group. 

Fig. 17 is a flowchart that shows the processing of communication controller 40 
(S24) shown in Fig. 6. 

As shown in Fig. 17, at step 240 (S240) communication controller 40 makes 
judgment whether or not Ready Queue of scheduler 344 (Fig. 1 1) is vacant. If vacant, 
then it stays in the process of S240, and in the other, contrary case it proceeds to the 
process of S242. 

At step 242 (S242), communication controller 40 picks up a drawing command 
from the top of Ready Queue in scheduler 344. 

At step 244 (S244), communication controller 40 reads out pixel data from frame 
memory 1 14 as the need arises, and generates packets which contain drawing commands 
etc. 

At step 246 (S246), communication controller 40 controls the communication 
control apparatus 126 in order to have it transfer the packets generated in the process of 
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S244 to display apparatus 16 via communication channel 22 (Fig. 1). 

At step 248 (S248), communication controller 40 judges whether or not the 
drawing command contained in the packet that was transferred to display apparatus 16 in 
the process of S246 is the last command in the relevant group. If it is the last drawing 
command in the group, then it proceeds to the process of S250. However, in the other 
case it returns to the process of S240. 

At step 250 (S250), communication controller 40 operates timer 36 to activate the 
timer processing function that monitors timeout for wait for ACK signal corresponding to 
the group transferred in the process of S246. 

In reference to Fig. 18 and Fig. 19, operation of image processing apparatus 1 is 
further explained hereunder. Fig. 18 is a sequence chart that illustrates the process from 
the stage when drawing commands are issued from application program 30 (Fig. 5) 
through when they enter the queue of scheduler 344 via OS 32. 

Fig. 19 is a sequence chart that shows the process where communication controller 
40 (Fig. 6) picks up the drawing commands from the queue of scheduler 344 and transfers 
them to display apparatus 16. 

As shown in Fig. 18, application program 30 calls graphics API to issue drawing 
request for operating system 32 (Request 1). Upon receipt of the above request, OS 32 
calls designated function which is exported to OS 32 by graphics driver 34, and issues a 
drawing command to command analysis routine 340 in graphics driver 34 (Request 2). 

Upon receipt of the above request 2, command analysis routine 340 inquires 
scheduler 344 whether or not the drawing command is immediately executable (Request 
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3). Upon receipt of the above request 3, scheduler 344 examines whether or not the 
drawing command is immediately executable and responds to command analysis routine 
340 (Response 4). 

In the above process of response 4, if scheduler 344 makes judgment that the 
drawing command is immediately executable and responds to that effect, command 
analysis routine 340 issues a drawing command to drawing routine 342 (Request 5). 
Drawing routine 342 carries out the drawing process in accordance with the drawing 
command received in the process of request 5, and stores the generated image data in 
frame memory 1 14. Upon completion of the drawing process, drawing routine 342 notifies 
command analysis routine 340 of the normal completion of drawing process (Response 6). 

Upon receipt of the notice of normal completion of drawing process in the process 
of Response 6, command analysis routine 340 adds the drawing command to the queue of 
scheduler 344 (Request 7). 

Scheduler 344 replies to command analysis routine that the drawing command has 
duly been added to the queue (Response 8). Command analysis routine 340 notifies 
operating system 32 of the completion of drawing process (Response 9). Operating system 
32 notifies application program 30 of the completion of drawing process (Response 10). 

Furthermore, as shown in Fig. 19, communication controller 40 picks up drawing 
commands from the queue of scheduler 344 and transfers them to display apparatus 16. 
In other words, communication controller 40 requests scheduler 344 to pick up a drawing 
command in Ready status from the queue (Request 1 1). In response to the above Request 
11, scheduler 344 passes communication controller 40 one of the drawing commands in 
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Ready status (Response 12). 

Communication controller 40 generates a packet and transfers it to display 
apparatus 16 (Request 13). In this case "drawing" only means that relevant processing is 
conducted by computer 10 toward frame memory 1 14, and does not mean that the image 
is actually displayed on display 1 14. 

Communication controller 40 requests the activation of timer designating the 
timeout value which indicates a lapse of time between the transfer of drawing commands 
and the returning of ACK signal (Request 14). Timer 36 notifies communication 
controller 40 of normal activation of timer (Response 15). 

Display apparatus 16 notifies communication controller 40 of the normal 
completion of drawing process (Response 16). Upon receipt of the above Response 16, 
communication controller 40 requests scheduler 344 the change of interdependent 
relations among the drawing commands (Request 17). 

Scheduler 344 renews the interdependent relations among the drawing commands 
and suspends the timer processing of timer 36 (Request 18). Timer 36 notifies scheduler 
344 of the normal suspension of timer processing (Response 19). 

Scheduler 344 notifies communication controller 40 of the normal completion of 
the processing in connection with the above Request 17 (Response 20). In the event that 
Response 16 is not returned even after a lapse of certain time (i.e. designated timeout 
value) since timer activation at above Request 14, timer requests scheduler to retransfer 
the drawing commands (Request 21). 

As described above, a data transferring apparatus and method according to the 
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present invention enable the efficient transfer of image data in such a case, for instance, as 
to connect a high resolution display apparatus to computer. 

While the invention has been described in terms of several preferred embodiments, 
those skilled in the art will recognize that the invention can be practiced with modification 
5 within the spirit and scope of the appended claims. 
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